A computing device may be characterized by its Instruction Set Architecture (ISA). Typically, a computing device may include Operating System (OS) services, and the OS services may include the runtime library (LIB) services, developed for the ISA of the computing device, to help application developers develop applications to operate on the computing device. If the application is written for an ISA other than the ISA for the computing device, the application may need to be emulated. Specifically, emulation allows an application (written for a first ISA) to execute on a computing device's architecture (which uses a second ISA). ISA dependent portions of applications may include function calls to source LIB services, which need to be emulated using target LIB services. Further, ISA dependent portions of applications may include callback functions (e.g., functions that call back from an ISA dependent runtime LIB to an emulated application, functions that call back to source LIB services that need to be emulated). Such callbacks may not be discovered until runtime, thereby rendering traditional approaches (e.g., binary translation) ineffective in bridging the two ISAs.
To execute the above applications, the application may need to be linked. Linking produces an executable program from compiled modules (e.g., libraries) by resolving interconnection references (e.g., interconnection between a library routine called by an application). This linking (also called “loading” at times herein) may be done dynamically via a binary translation system (BT). Dynamic linking defers much of the linking process until a program starts running A dynamic linker may be part of an OS that loads and links shared libraries for an executable when the executable is executed. The technique may use a procedure linking table (PLT), global offset table (GOT), and an indirect jump to direct an application's library call to a target function in a dynamic linked library.